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1.  INTRODUCTION 

1.1  Purpose  of  CSTAR 

The  purpose  of  Combat  Synthetic  Training  Assessment  Range  (CSTAR)  is  to  create  a 
collective  training  system  designed  to  enhance  integrated  combined  arms  training  for 
brigades  in  garrison  and  at  the  Combat  Training  Centers  (CTC).  Its  primary  purpose  is 
the  development  and  evaluation  of  battle  command  capabilities  that  accrue  from 
organizational  and  technological  changes  at  the  brigade  level  that:  1.  increase  battle  space 
(time,  scope,  and  resolution);  2.  promote  the  concept  of  the  integrated  reconnaissance;  3. 
enhance  the  capability  for  “battlefield  visualization”;  4.  provide  opportunities  for 
“dynamic  targeting”.  Its  secondary  focus  is  equipment-oriented  collective  training  for  the 
Military  Intelligence  (MI)  Company  (DS).  In  this  role,  it  fulfills  a  subset  of  the 
Intelligence  Electronic  Warfare  (lEW)  Tactical  Proficiency  Trainer  objective.  It 
provides:  1.  stimulation  and  crew  training  on  the  company’s  primary  mission  equipment: 
Command  Ground  Station  (CGS);  Unmanned  Air  Vehicle  (UAV)  Tactical  Control 
System  (TCS);  and  All  Source  Analyst  System-Remote  Workstation  (ASAS-RWS);  2. 
“system  of  systems  integration  of  this  equipment  for  company  operation;  3.  vertical 
integration  of  the  company  with  the  Division  Analysis  Control  Element;  4.  horizontal 
integration  with  the  Brigade  S2  and  Fire  Support  Officer. 

1.2  Purpose  and  Scope  of  Document 

The  purpose  of  this  document  is  to  report  the  results  of  the  CSTAR  Feasibility  Analysis 
Study  (FAS).  The  purpose  of  the  FAS  was  to  select  the  exercise  driver  which  will  best 
meet  the  needs  for  CSTAR,  and  to  identify  how  the  exercise  driver  might  be  integrated 
with  the  instrumented  live  exercise  and  the  sensor  models.  This  document  discusses  the 
constructive  combat  model  recommended  to  serve  as  the  exercise  driver  for  CSTAR  and 
identifies  the  issues  related  to  integrating  the  exercise  driver  with  the  other  systems. 

1.3  Organization  of  the  Document 
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The  initial  portion  of  this  FAS  report  is  organized  to  discuss  our  study  approach, 
assumptions,  a  comparison  of  each  of  the  models,  and  technical 
findings/recommendations,  including  a  discussion  on  the  recommended  solution  and 
alternate  solutions.  This  is  followed  by  an  analysis  of  the  recommended  solution  and  the 
alternatives  with  considerations  of  technical  risk,  cost  and  schedule  impacts. 
Configuration  drawings,  sub-component  descriptions,  capabilities  and  advantages  and 
disadvantages  of  the  recommended  solution  are  provided.  Appendix  A  provides  general 
data  and  facts  in  matrix  form  for  the  constructive  simulation  models  evaluated.  Appendix 
B  provides  the  CSTAR  configuration  for  both  the  National  Training  Center  (NTC)  Ft. 
Irwin,  CA.  and  homestation.  Ft.  Hood,  TX.  exercises. 


2.  STUDY  APPROACH 


In  accordance  with  the  Government  Statement  Of  Work  (SOW)  for  CSTAR,  initial 
analysis  efforts  were  to  determine  the  optimum  exercise  driver  based  on  the  materiel 
requirements  summary  for  the  CSTAR  Warfighter  Rapid  Acquisition  Program  (WRAP) 
Project.  In  the  interest  of  time,  constructive  simulation  candidates  that  did  not  meet 
several  of  the  basic  CSTAR  requirements  were  not  fully  evaluated 

The  FAS  was  conducted  over  a  ninety  day  period  of  time.  The  FAS  involved  fact 
finding,  analysis  of  technical  data,  and  on-site  visits  to  the  training  sites  at  Ft  Irwin,  CA. 
(NTC)  and  Ft  Hood,  TX.  During  the  analysis  process  three  in  progress  reviews  (IPR) 
were  conducted  with  the  customer. 

2.1  Assumptions 

The  FAS  findings  and  success  of  CSTAR  are  dependent  upon  several  assumptions. 
These  assumptions  are  discussed  in  more  detail  in  follow-on  paragraphs  of  the  report: 

•  The  exercise  driver  should  be  an  entity  based  model. 

•  The  exercise  driver  should  be  compliant  with  the  Distributed  Interactive  Simulation 
(DIS)  standard  or  the  High  Level  Architecture  (HLA)  standard. 

•  The  core  scenario  (live  units  at  NTC  and  the  training  scenario  at  Ft.  Hood)  and  the 
wrap-around  scenario  do  not  need  to  interact  with  each  other,  within  the  constructive 
simulation. 

•  The  program  has  a  short  life.  Functional  test  will  occur  in  late  1998. 
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3.0  THE  BASIC  CSTAR  SYSTEM 

3.1  Description 

CSTAR  is  a  suite  of  hardware  and  software  that  integrates  a  training  force  with  elements 
from  a  constructive  simulation  and  a  number  of  sensor  models.  A  constructive 
simulation  wraps  around  the  training  force  providing  flank  and  rear  area  enemy  units  to 
create  a  larger  virtual  scenario.  Units  from  the  virtual  scenario  are  used  to  stimulate 
UAV,  Joint  Surveillance  Target  Attack  Radar  System  (JSTARS),  Q36/37,  and  SIGINT 
sensor  models.  The  sensor  model  outputs  exercise  Militeiry  Intelligence  (MI)  units  on 
their  primary  mission  equipment.  There  are  two  basic  CSTAR  configurations.  At  Ft 
Irwin,  the  training  force  will  be  instrumented  live  units.  At  Ft.  Hood,  the  training  force  is 
the  units  from  a  constructive  entity  level  simulation.  The  goal  is  to  increase  battle  space, 
promote  the  concept  of  the  integrated  reconnaissance,  enhance  the  capability  for 
“battlefield  visualization”  and  provide  opportunities  for  “dynamic  targeting”. 

CSTAR  is  a  continuation  of  the  CSTTAR  (Combat  Synthetic  Test  and  Training  Range). 


3.2  Requirements  for  the  Exercise  Driver 

CSTAR  Constructive  Simulation  requirements  include: 

Constructive  scenario  development  capability  resident  at  NTC  enabling  the  depiction  of  a 
300  X  300  km,  wrap-around  scenario  portraying  flank  and  second-echelon  forces  outside 
the  instrumented  maneuver  box  or  superimposed  over  the  “live”  maneuver  box  (for 
artillery  and  air  defense  artillery,  (ADA)  capabilities,  not  routinely  exercised  during  a 
rotation).  The  scenario  tool  must  depict  forces  at  the  entity  level  of  resolution  (vice 
aggregate  simulation)  and  have  the  flexibility  to  enable  NTC  controllers  to  easily  adjust 
the  scenario  to  accommodate  late  adjustments  in  the  live  OPFOR  scheme  of  maneuver. 
All  constructive  simulations  options  should  be  explored  for  options  consistent  with  HLA 
standards  and  migration  strategies  to  achieve  the  following  minimum  capability 
standards: 

(1)  8000  entity  capacity  within  a  300  x  300  km  scenario  box 

(2)  units/platforms  capable  of  moving  a  different  speeds  with  varied  distance 
between  units  or  platforms  (e.g.  rapid  assumption  of  tactical  formations  consistent  with 
type  of  unit,  organic  equipment,  and  scenario  controller  commands) 

(3)  organization  of  entities  into  units  within  a  multi-level  hierarchy 

(4)  platform  identification  and/or  destruction  by  name 

(5)  at  least  225  separate  system  types  with  weapon  systems  firing  signatures 

(6)  rotary  and  fixed-wing  aircraft 

(7)  individual  soldiers  (e.g.  SA18  gunner) 
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(8)  ability  to  set  unit  view  fans 

(9)  scenarios  capable  of  running  unattended  for  24  hours 

(10)  exercise  controller  ability  to  resurrect,  create,  and  enplace  units  on  demand 

(11)  end  save  and  checkpoint  save  features 


3.3  Requirements  for  CSTAR 

CSTAR  requirements  include: 

Capability  to  capture  all  (e.g.  tracks,  tanks,  bulldozers)  live  force  play  through  the  NTC 
instrumentation  system  and  convert  this  data  to  simulation  protocols  where  it  can  be 
integrated  with  constructive  simulation  to  create  a  single  virtual  scenario.  This  capability 
must  be  “upwardly  compatible“  with  programmed  changes  in  the  NTC  instrumentation 
system.  It  is  highly  desirable  that  this  data  be  normalized  for  WGS-84  and  support 
locational  accuracy  less  than  or  equal  to  70  meters. 


3.4  CSTTAR 

CSTTAR  was  an  experiment  conducted  at  the  National  Training  Center  (NTC)  to  create  a 
suite  of  hardware  and  software  to  integrate  an  instrumented  live  force  with  elements  from 
a  constructive  simulation  and  a  number  of  sensor  models.  The  constructive  simulation 
was  used  to  generate  flank  and  rear  area  enemy  units  within  the  virtual  scenario  that  could 
stimulate  sensor  models  to  exercise  MI  units  on  their  primary  mission  equipment.  The 
goal  was  to  prove  that  such  a  link  was  possible. 

CSTTAR  system  consisted  of  live  instrumented  units,  a  constructive  entity  level 
simulation,  a  DIS  converter,  a  Protocol  Data  Unit  (PDU)  data  logger,  a  High  Resolution 
System  Stimulator  (HRSS),  and  a  number  of  sensor  models. 

The  live  units  were  part  of  a  training  exercise.  Their  movements  and  activities  were 
tracked  by  the  Central  Instrumentation  System  (CIS).  The  NTC-CIS  input  the  position  of 
the  live  units  to  a  DIS  Converter  which  put  Entity  State  PDUs  for  the  live  elements  on  the 
DIS  network. 

CSTTAR  used  Janus  6000  for  the  constructive  wrap-around  exercise  driver.  Janus  6000 
is  a  DIS  version  of  Janus  tailored  to  the  specific  needs  of  the  experiment.  Capabilities  of 
Janus  6000  include: 

1 .  Plays  8000  entities 

2.  Can  aggregate  entities  and  units  into  higher  level  units 

3.  Aggregated  units  can  be  given  routes  and  deployed  as  a  unit 
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4.  Puts  out  DIS  entity  state  PDUs 

5.  Adjustable  PDU  rate 

6.  Unit  hide  feature 

7.  Random  unit  attrition 

The  hide  feature  allows  Janus  to  turn  off  sending  PDUs  for  certain  units.  In  the 
experiment  scenarios,  some  units  were  both  live  and  constructive.  The  DIS  converter 
filtered  out  PDUs  of  live  units  outside  of  the  live  play  box.  Janus  was  responsible  for 
controlling  and  sending  out  PDUs  for  units  while  they  moved  through  the  wrap-around 
area.  When  units  crossed  the  boundary  between  the  wrap-around  area  and  the  inner  live 
play  box,  the  responsibility  for  generating  PDU  for  these  units  changed.  The  hide  feature 
was  essential  for  the  CSTTAR  experiment  but  has  not  been  kept  for  Janus  6.88D. 

The  ability  to  give  movement  routes  to  higher  level  units  greatly  reduces  the  amount  of 
operator  interaction  required.  The  implementation  of  this  capability  in  Janus  6000  tried 
to  maintain  the  unit’s  formation  by  ignoring  terrain  effects  on  the  movement.  Janus 
considered  two  movement  environments:  on  road  and  cross  country.  Another  side  effect 
occurs  when  the  unit  changes  direction.  To  maintain  the  unit  formation,  the  unit 
formation  is  simply  rotated  around  the  lead  element.  Elements  of  the  unit  far  from  the 
lead  entity  will  jump,  sometimes  great  distances.  Although  this  implementation  is 
acceptable  for  the  wrap-around  scenario,  it  would  not  be  for  primary  training  exercise 
conducted  Ft.  Hood. 

For  CSTTAR  Janus  was  run  from  White  Sand  Missile  Range  (WSMR)  on  a  single  HP 
Cl 80  workstation  and  was  connected  to  the  NTC  with  a  T1  line.  The  addition  of  DIS 
capability  did  not  adversely  affect  Janus  performance.  The  T1  line  was  not  a  dedicated 
line.  Generally,  the  T1  line  was  sufficient  to  handle  the  network  traffic  between  WSMR 
and  NTC.  Network  problems  that  did  arise  were  due  to  the  high  volume  of  network 
traffic  from  other  sources.  The  potential  bottleneck  is  the  HRSS’  ability  to  process  the 
PDUs  it  receives.  The  load  on  the  HRSS  can  be  reduced  or  leveled  out  by  fine  tuning 
Janus  parameters  which  set  the  frequency  units  are  updated,  the  fraction  of  units  updated 
per  cycle,  and  the  interval  between  PDUs. 

Janus  6000  did  not  interact  with  the  live  exercise.  Significant  performance  gains  could  be 
realized  because  the  wrap-around  Janus  exercise  had  no  knowledge  of  the  live  entities. 
The  Line  Of  Sight  (LOS)  calculations  performed  in  target  detection  is  the  most  intensive 
user  of  CPU  time  in  Janus.  Janus  does  not  detect  units  belonging  to  the  same 
workstation,  so  the  most  CPU  intensive  algorithm  was  not  exercised.  Although  LOS 
calculations  were  not  performed,  the  process  of  filtering  out  large  numbers  of  same 
workstation  units  in  the  target  acquisition  process  had  a  significant  affect  on  performance. 
To  improve  performance,  the  Janus  data  base  was  manipulated  to  reduce  the  distance  to 
which  units  searched  for  targets.  In  other  versions  of  Janus,  such  as  the  training  versions 
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(Janus  6.3  and  7.0),  a  scenario  of  1000  to  1200  units  on  terrain  with  a  light  to  moderate 
number  of  terrain  features  engaged  in  an  intense  fire  fight,  Janus  can  just  run  in  real  time. 
At  Ft  Hood  the  simplest  and  easiest  implementation  would  be  to  run  a  single  scenario  that 
includes  the  main  training  exercise  of  BLUFOR  and  OPFOR  units  and  the  wrap-around 
OPFOR  units.  It  would  be  unrealistic  to  expect  Janus  to  run  such  a  scenario  on  present 
training  hardware  in  real  time.  The  only  feasible  Ft  Hood  exercise  configuration  is  to  run 
two  or  more  Janus  scenarios;  one  for  the  main  training  exercise  and  the  other  scenarios 
for  the  wrap-around  portion.  The  main  training  scenario  and  the  wrap-around  scenarios 
would  need  to  use  different  databases. 

The  HRSS  receives  PDUs  from  Janus  and  the  instrumented  live  units  from  the  DIS 
network.  The  HRSS  performs  three  functions.  It  maintains  the  single  entity-level 
Ground  Truth  of  the  virtual  scenario.  The  HRSS  can  also  de-aggregate  high  level 
organizations  down  to  the  entity  level  using  posture-specific  deployment  templates.  The 
de-aggregation  function  was  not  required  for  Janus  6000,  but  could  be  used  if  Janus 
aggregated  units  or  if  an  aggregate  level  constructive  simulation  such  as 
Brigade/Battalion  Battle  Simulation  (BBS)  or  Corps  Battle  Simulation  (CBS)  were  used. 
The  third  function  of  the  HRSS  is  to  act  as  an  interface  between  the  virtual  scenario  and 
the  sensor  models.  Only  information  on  units  within  the  sensor’s  area  of  interest  are 
passed  to  the  sensor  model. 


4.0  MODEL  COMPARISON 

Eight  models  and  systems  were  examined:  Joint  Conflict  and  Tactical  Simulation 
(JCATS),  Joint  Conflict  Model  (JCM),  Joint  Tactical  Simulation  (JTS),  Janus,  BBS, 
Synthetic  Theater  Of  War  (STOW),  ModSAF,  and  CBS.  Five  of  the  systems,  JCATS, 
JCM,  JTS,  Janus,  and  ModSAF,  are  entity  based  models.  Two  of  the  systems,  BBS  and 
CBS  are  aggregate  level  models.  The  other  system,  STOW,  is  not  a  model  itself.  The 
functionality  of  each  system  was  compared  against  the  requirements  for  the  CSTAR 
exercise  driver.  Other  considerations  included  cost,  availability,  and  hardware. 

None  of  the  systems  met  all  of  the  requirements.  All  of  the  entity  based  models  met  the 
following  requirements: 

(2)  units/platforms  capable  of  moving  a  different  speeds  with  varied  distance 
between  units  or  platforms  (e.g.  rapid  assumption  of  tactical  formations  consistent  with 
type  of  imit,  organic  equipment,  and  scenario  controller  commands) 

(5)  at  least  225  separate  system  types  with  weapon  systems  firing  signatures 

(6)  rotary  and  fixed-wing  aircraft 

(7)  individual  soldiers  (e.g.  SA18  gunner) 

(8)  ability  to  set  unit  view  fans 
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(9)  scenarios  capable  of  running  unattended  for  24  hours 
(11)  end  save  and  checkpoint  save  features 

Strictly  interpreted,  Janus  does  not  meet  300  x  300  km  play  box  requirement  and  JTS 
does  not  meet  the  8000  entity  capacity  requirement.  This  is  not  a  serious  drawback  for 
the  models  because  multiple  scenarios  can  be  run  simultaneously  to  achieve  the  desired 
results. 

At  this  point,  HLA  compliance  does  not  appear  to  be  critical.  Only  ModSAF  currently 
has  a  HLA  bridge.  The  HRSS  is  an  essential  piece  of  the  CSTAR  configuration  and  it  is 
not  HLA  compliant  at  this  time.  A  HLA  bridge  would  have  to  be  developed  to  replace 
the  DIS  converter  to  bridge  between  the  instrumented  live  exercise  and  the  HLA  network. 
The  alternative  is  to  use  DIS  until  the  selected  constructive  model,  HRSS,  and  HLA 
converter  become  available.  Only  ModSAF  is  DIS  compliant  in  the  narrow  sense.  The 
other  entity  level  models  have  bridges  or  a  limited  DIS  capability  built  into  them  which 
make  the  models  DIS  compatible.  For  the  purposes  of  CSTAR,  this  limited  capability  is 
sufficient.  The  most  important  function  is  the  ability  to  produce  entity  state  PDUs.  The 
wrap-around  scenario  can  be  independent  of  the  exercise  scenario  as  demonstrated  by 
CSTTAR. 

The  number  of  operators,  and  thus  workstations,  required  to  run  an  8000  entity  scenario  is 
an  important  factor  in  determining  the  best  constructive  simulation.  Realistically,  an 
experienced  operator  can  interact  with  200  to  300  icons.  With  more  icons  the  operator 
becomes  overwhelmed.  With  large  numbers  of  icons,  the  display  screen  becomes 
cluttered  and  it  is  difficult  to  locate  particular  units.  It  is  also  difficult  to  react  to  events  in 
a  timely  manner.  This  limiting  factor  applies  to  all  of  the  simulations.  There  are  some 
things  that  can  mitigate  these  problems  and  even  increase  the  number  of  icons  that  an 
operator  can  manage. 

First,  a  carefully  plaimed  and  coordinated  scenario  can  significantly  reduce  the  amount  of 
interaction  required.  In  effect,  the  burden  of  interacting  with  the  scenario  is  shifted  from 
execution  to  the  set  up  or  planning  phase.  An  advantage  of  shifting  interaction  to  the  set 
up  phase  is  that  a  number  of  canned  scenarios  can  be  developed  as  an  one  time  effort. 
The  scenarios  are  then  reused  for  different  exercises.  For  Ft  Irwin,  where  there  is  a 
limited  number  attack  corridors,  this  approach  can  save  a  lot  of  man  power. 

Second,  the  ability  to  organize  entities  into  hierarchical  aggregates  and  manipulate  those 
aggregates  allows  an  operator  to  control  more  entities.  There  are  two  possible,  distinct 
levels  of  aggregation.  At  the  graphical  display  level,  a  hierarchy  of  unit  icons  are 
displayed  at  the  workstation.  Subordinate  units  can  be  displayed  by  de-aggregating 
higher  level  aggregates  and  higher  level  units  can  be  displayed  by  aggregating 
subordinate  units.  Aggregation  at  the  graphical  display  level  can  reduce  screen  clutter 
and  ease  the  operators  job.  It  improves  performance  by  reducing  the  amount  of  graphics 
that  have  to  be  updated.  At  the  control  level,  the  actions  assigned  to  a  unit  are  propagated 
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down  the  hierarchy  to  the  entity  level.  Hierarchical  control  reduces  the  number  of  key 
strokes  and  mouse  picks  necessary  to  control  a  large  force.  Both  types  of  aggregation  can 
be  used  to  increase  the  number  of  entities  that  can  be  manipulated  by  the  operator  and 
thus  reduce  the  number  of  operators  and  workstations  required  to  run  a  scenario.  Most 
models  implement  both  types  of  aggregation.  The  details  of  the  implementation  of  the 
hierarchical  aggregation  at  the  control  level  was  critical  to  the  evaluation  process. 

The  constructive  simulation  must  provide  some  mechanism  to  deal  with  the  boundary 
between  the  live  exercise  and  the  wrap-around  scenario.  In  a  fully  DIS  compliant 
environment,  control  or  ownership  of  an  entity  can  be  passed  between  federates,  in  this 
case  the  live  instrumented  exercise  through  the  DIS  converter  and  the  constructive 
simulation.  In  CSTTAR,  this  was  accomplished  by  having  the  DIS  converter  stop 
sending  out  entity  state  PDUs  for  live  units  leaving  the  live  play  box  and  having  Janus 
stop  sending  out  PDUs  for  constructive  units  leaving  the  wrap-around  box.  An 
alternative  approach  for  the  constructive  simulation  is  the  ability  to  add  units  to  the 
simulation  when  a  live  unit  leaves  the  play  box  and  to  delete  units  from  the  simulation 
when  it  leaves  the  wrap-around  area. 

The  constructive  simulation  does  not  need  to  be  able  to  capture  the  live  exercise  play, 
because  the  HRSS  maintains  the  virtual  simulation.  If  the  constructive  simulation  is 
unaware  of  the  live  entities,  there  is  no  chance  of  interaction  between  the  two  realms. 
Otherwise,  interaction  can  be  limited  by  putting  the  constructive  units  in  a  hold  fire 
status.  Constructive  units  will  still  try  to  acquire  the  live  units  which  might  put  too  much 
of  a  performance  burden  on  the  simulation.  The  time  and  resources  spent  trying  to 
acquire  targets  can  be  reduced  by  shortening  the  detection  or  visibility  range  of  the 
constructive  units  in  the  wrap-around  scenario. 


4.1  JCATS 

4.1.1  Model  Description 

The  Joint  Conflict  and  Tactical  Simulation  (JCATS)  is  a  multi-sided  interactive  entity 
level  conflict  simulation  to  be  used  as  an  exercise  driver  and  a  tool  for  training,  analysis, 
and  mission  planning.  JCATS  uses  a  client-server  architecture.  The  server  manages  the 
battle.  Clients  handle  all  the  graphics  displayed  at  the  local  workstation  as  well  as 
requested  LOS  fan  calculation  and  display.  Later  releases  should  adhere  to  the  HLA 
standard.  JCATS  can  model  about  20,000  entities  on  a  play  box  of  600x600  kilometers. 
JCATS  models  dismounted  infantry,  tracked  and  wheeled  vehicles,  fixed  and  rotary  wing 
aircraft,  ships,  and  submarines.  JCATS  provides  very  detailed  modeling  of  small  group 
tactics  in  rural  or  urban  terrain  modeling  day  or  night  operations  with  artificial  lighting. 
It  allows  for  dynamic  hierarchical  aggregation  and  de-aggregation  of  units  during  the 
game  allowing  the  user  to  play  large  numbers  of  entities  with  fewer  operators.  JCATS 
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should  be  able  to  run  a  two  week  exercise  without  interruption.  It  has  the  ability  to 
introduce  new  entities  dynamically  into  the  game.  Other  features  include  a  direct  fire 
fratricide  model,  tracking  of  missed  shots,  direct  fire  suppression,  fatigue,  resupply  of 
fuel  and  ammunition,  breaching  of  barriers,  weather  and  terrain  affects  on  movement  and 
acquisition,  and  a  high  resolution  minefield  model. 

4.1.2  Advantages 

The  initial  JCATS  release  will  meet  or  exceed  all  of  the  requirements  for  the  simulation 
driver  for  CSTAR  except  the  requirement  that  the  model  be  HLA  or  DIS  compliant.  It  is 
the  newest  entity  level  constructive  simulation  and  incorporates  features  from  other 
combat  simulations,  especially  JCM  and  JTS,  as  well  as  new  features  not  found 
elsewhere. 

•  JCATS  has  a  client-server  architecture  that  allows  some  CPU  intensive  functions  to 
be  performed  by  the  client.  JCATS  should  be  able  to  play  about  20000  entities  in  real 
time. 

•  JCATS  can  play  a  600x600  km  play  box. 

•  There  are  plans  to  make  JCATS  HLA  compliant  in  the  future. 

•  JCATS  has  separate  fixed  and  rotary  wing  aircraft  models.  The  fixed  wing  model 
gives  JCATS  a  better  representation  of  fixed  wing  play  than  does  Janus. 

•  JCATS  should  be  able  to  run  a  two  week  exercise  without  interruption. 

•  Has  the  capability  to  introduce  new  entities  dynamically  during  the  game.  Entity 
characteristics  can  be  modified  during  the  game.  It  has  the  ability  to  remove  entities 
during  the  game.  JCATS  is  planning  to  have  a  resurrection  function,  but  it  may  not 
be  in  version  1 .0 

•  It  runs  on  the  same  hardware,  HP  9000  Series  700  workstations,  as  the  current  tactical 
combat  trainer  simulation.  A  HP  C  or  J  class  workstation  is  recommended  for  the 
server. 

•  Aggregated  units  can  be  given  movement  routes.  Units  will  attempt  to  stay  in 
formation  during  maneuvers.  There  is  a  set  of  standard  formations  that  can  be  used  or 
the  user  can  define  the  formation  of  the  unit.  The  aggregated  unit  moves  at  the  speed 
of  the  slowest  moving  element.  If  an  element  stops  for  obstacles  or  terrain  features, 
or  becomes  mobility  killed,  that  element  is  dropped  from  the  unit,  and  the  aggregated 
unit  continues.  This  level  of  aggregate  control  should  allow  operators  to  manage  200 
or  more  entities. 

4.1.3  Disadvantages 
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•  JCATS  1.0  is  not  scheduled  to  be  released  until  late  April  1998.  Initial  software 
releases  are  not  usually  as  stable  and  reliable  as  mature  products.  The  initial  release 
may  not  be  DIS  compliant  and  will  not  be  HLA  compliant.  JCATS  has  not  been 
tested  in  a  distributed  environment  with  other  simulations  or  live  elements. 

4.1.4  Issues 

•  JCATS  version  1 .0  may  not  support  dynamic  aggregation  and  de-aggregation  of  units 
during  play.  If  not,  JCATS  may  not  have  the  flexibility  needed  to  easily  manage 
large  numbers  of  entities. 

•  The  initial  JCATS  release  will  not  be  HLA  compliant.  Initially,  it  was  plaimed  to 
modify  and  use  the  DIS  bridge  of  JTS.  Recent  events  have  put  this  plan  in  jeopardy. 
The  JCATS  Configuration  Control  Board  (CCB)  meets  in  December  1997  and  will 
decide  what  distributive  functionality  will  be  used  and  when  it  will  be  available. 
JCATS  is  not  a  viable  option  for  CSTAR  without  HLA  or  DIS  functionality.  If 
JCATS  is  made  DIS  compliant,  it  can  be  used  without  modification  to  the  HRSS  or 
the  DIS  converter  for  the  instrumentation  system.  If  JCATS  is  made  HLA  compliant 
instead,  the  HRSS  and  DIS  converter  will  have  to  be  modified. 

•  JCATS  may  not  be  released  in  time  for  the  initial  CSTAR  test.  A  Beta  test  version 
may  be  available  before  the  April  1998  release  date.  Once  a  stable  HLA/DIS  version 
of  JCATS  becomes  available,  it  will  be  worth  while  to  try  it  in  the  CSTAR 
configuration. 

•  The  treatment  of  aggregated  units  cuts  comers  that  places  JCATS  between  an  entity 
and  aggregate  level  simulation.  Like  Janus  6000,  the  aggregate  movement  algorithm 
largely  ignores  terrain  effects  on  individual  entities.  JCATS  moves  aggregated  units 
from  the  unit’s  center  of  mass,  then  disperses  the  entities  according  to  a  formation 
template.  Entities  within  aggregates  do  not  acquire  targets.  The  aggregate’s  sensors 
are  pooled.  Acquisition  is  performed  for  each  type  of  sensor  from  the  aggregate’s 
center  of  mass.  Direct  fire  engagements  are  performed  on  the  entity  level  and  the 
shooter  must  have  LOS  to  the  target. 

•  JCATS  would  require  some  upgrades  to  the  current  hardware  suite  used  by  Janus. 
The  original  Janus  hardware  suite  used  HP  series  9000,  715-50  workstations.  The 
workstations  have  64  Mbytes  of  Random  Access  Memory  (RAM)  and  a  1  Gbyte 
internal  disk  drive.  The  simulation  host  workstation  has  an  additional  2  Gbyte 
external  disk  drive.  Several  sites  have  already  upgraded  their  host  workstations. 
JCATS  client  workstations  can  run  on  the  current  715-50  workstations,  although  128 
Mbytes  of  RAM  and  2  Gbyte  disk  drives  are  recommended.  The  server  workstation 
can  mn  on  the  715  class,  but  the  more  powerful  C  or  J  class  machines  are 
recommended.  The  server  workstation  requires  a  minimum  of  128  Mbytes  and  256  is 
recommended.  It  also  requires  a  minimum  of  4  Gbytes  hard  disk  capacity,  and 
recommends  6  Gbytes.  The  minimum  needed  to  upgrade  the  current  hardware  suite  is 
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the  purchase  of  a  C  or  J  class  workstation  and  4  Gbytes  of  external  disk  drive 
capacity. 


4.2  JCM 

4.2.1  Model  Description 

The  Joint  Conflict  Model  (JCM)  is  a  multi-sided  interactive  entity  level  conflict 
simulation  used  as  an  exercise  driver  and  a  tool  for  training,  analysis,  and  mission 
planning.  JCM  is  DIS  compliant.  JCM  can  model  about  20,000  entities  on  a  play  box  of 
600x600  kilometers.  JCM  models  dismounted  infantry,  tracked  and  wheeled  vehicles, 
fixed  and  rotary  wing  aircraft,  and  brown  water  naval  operations.  JCM  can  run  a 
continuous  two  week  exercise.  It  has  the  ability  to  introduce  new  entities  dynamically 
into  the  game.  Other  features  include  resupply,  breaching  of  barriers,  weather  and  terrain 
affects  on  movement  and  acquisition,  command  and  control  graphical  operations 
planning,  and  a  high  resolution  minefield  model. 

4.2.2  Advantages 

•  JCM  is  available  now. 

•  JCM  can  play  about  20000  entities  in  real  time. 

•  JCM  can  play  a  600x600  km  play  box. 

•  JCM  is  DIS  compatible. 

•  JCM  has  separate  fixed  and  rotary  wing  aircraft  models.  The  fixed  wing  model  gives 
JCM  a  better  representation  of  fixed  wing  play  than  does  Janus. 

•  JCM  is  able  to  run  a  two  week  exercise  without  interruption. 

•  JCM  has  the  capability  to  introduce  new  entities  dynamically  during  the  game.  Entity 
characteristics  can  be  modified  during  the  game. 

4.2.3.  Disadvantages 

•  JCM  runs  on  VAXA^MS  computers  and  DEC  Alpha  workstations  running  Open 
VMS.  The  existing  hardware  (HP  9000  series  700  workstations)  cannot  be  used. 

•  JCM  is  slated  to  be  phased  out  when  JCATS  is  released.  It  will  not  be  supported  after 
mid  1998. 

•  JCM  does  not  support  the  organization  of  entities  into  multi-level  hierarchies. 

•  Units  cannot  be  aggregated.  More  operator  interaction  is  required  to  control  a  force 
which  reduces  the  number  of  icons  that  can  be  controlled  on  a  workstation. 
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•  There  are  no  plans  to  make  JCM  HLA  compliant. 

4.2.4  Issues 

•  JCM  has  a  short  future  because  it  is  being  replaced  by  JCATS.  JCM  does  meet  a 
number  of  critical  requirements  for  CSTAR:  entity  count,  play  box  size,  and  DIS 
compliance.  If  JCM  and  JCATS  ran  on  the  same  hardware  platforms,  JCM  would  be 
a  viable  interim  solution  to  JCATS. 


4.3  JTS 

4.3.1  Model  Description 

The  Joint  Tactical  Simulation  (JTS)  is  a  multi-sided  interactive  entity  level  conflict 
simulation  used  as  a  tool  for  training,  analysis,  and  mission  planning.  JTS  provides 
detailed  modeling  of  small  group  tactics  in  rural  or  urban  terrain  for  day  or  night 
operations  with  artificial  lighting.  JTS  can  model  2,000  entities  on  a  play  box  of 
600x600  kilometers.  JTS  models  dismounted  infantry,  tracked  and  wheeled  vehicles, 
fixed  and  rotary  wing  aircraft,  and  brown  water  naval  operations.  It  has  the  ability  to 
introduce  new  entities  dynamically  into  the  game.  Other  features  include  a  direct  fire 
fratricide  model,  tracking  of  missed  shots,  direct  fire  suppression,  fatigue,  resupply  of 
fuel  and  ammunition,  breaching  of  barriers,  weather  and  terrain  affects  on  movement  and 
acquisition  and  command  and  control  graphical  operations  planning. 

4.3.2  Advantages 

•  JTS  has  a  DIS  gateway. 

•  JTS  can  play  a  600x600  km  play  box. 

•  Has  the  capability  to  introduce  new  entities  dynamically  during  the  game. 

•  It  runs  on  the  same  hardware,  HP  9000  Series  700  workstations,  as  the  current  tactical 
combat  trainer  simulation. 

4.3.3  Disadvantages 

•  JTS  is  intended  for  small  group  tactics  on  very  detailed  terrain.  It  can  play  about 
2000  entities,  which  is  not  enough  for  CSTAR. 

•  JTS  will  not  be  supported  after  JCATS  is  released  in  mid  1998. 

•  JTS  does  not  support  the  organization  of  entities  into  multi-level  hierarchies. 
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•  Because  units  cannot  be  aggregated,  more  operator  interaction  is  required  to  control  a 
force  which  reduces  the  number  of  icons  that  can  be  controlled  on  a  workstation. 

•  ITS  also  requires  several  Commercial  Off  The  Shelf  (COTS)  software  packages. 

•  There  are  no  plans  to  make  JTS  HLA  compliant. 

4.3.4  Issues 

•  JTS  can  only  play  2000  entities.  Because  JTS  is  DIS  compliant,  a  number  of  JTS 
simulations  can  be  run  simultaneously  on  the  DIS  network  to  achieve  the  required 
number  of  entities. 

•  JTS  has  a  short  future  because  it  is  being  replaced  by  JCATS.  JTS  meets  the 
requirements  for  play  box  size  and  DIS  compliance  and  can  reach  the  entity  count 
requirement  by  running  multiple  scenarios.  Also  in  its  favor  is  that  it  runs  on  the 
same  hardware  as  the  current  training  model.  Its  major  drawbacks  are  that  it  requires 
COTS  software  and  it  does  not  support  a  multi-level  hierarchy  of  units. 
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4.4  Janus 

4.4.1  Model  Description 

Janus,  named  for  the  Roman  god  of  portals,  is  a  multi-sided  interactive  entity  level 
conflict  simulation  used  as  an  exercise  driver  and  a  tool  for  training,  analysis,  and 
mission  planning.  There  are  plans  to  make  Janus  HLA  compliant  in  the  future.  Janus 
models  dismounted  infantry,  tracked  and  wheeled  vehicles,  and  rotary  winged  aircraft. 
Janus  supports  dynamic  hierarchical  aggregation  and  de-aggregation  of  units  during  play. 
Janus  is  able  to  run  uninterrupted  for  up  to  two  weeks.  Janus  models  direct  fire  fratricide, 
direct  fire  suppression,  resupply  of  fuel  and  ammunition,  breaching  of  barriers,  weather 
and  terrain  affects  on  movement  and  acquisition.  It  has  a  high  resolution  minefield 
model. 

Janus  comes  in  several  variants.  The  version  being  considered  as  the  CSTAR  exercise 
driver  is  known  as  Janus  6.88D.  Janus  6.88D  is  DIS  compatible.  Janus  supports  dynamic 
hierarchical  aggregation  and  de-aggregation  of  units  during  the  game  allowing  the  user  to 
play  larger  numbers  of  entities  with  fewer  operators. 

4.4.2  Advantages 

•  Janus  is  the  army  tactical  combat  trainer.  It  is  fielded  at  over  forty  sites,  including  the 
National  Training  Center  (NTC)  and  Fort  Hood.  While  there  are  similarities  between 
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the  training  version,  there  are  significant  differences.  The  staffs  at  NTC  and  Ft  Hood 
are  familiar  with  Janus  and  would  need  little  retraining. 

•  Janus  6000  was  used  for  the  original  CSTTAR  tests.  Janus  met  the  goals  of  those 
tests.  Janus  6.88D  is  the  follow  up  to  Janus  6000. 

•  Janus  has  a  simple  and  intuitive  interface  for  the  operator.  Soldiers  can  be  taught  to 
interact  with  the  simulation  in  four  to  twelve  hours.  This  can  be  a  significant  factor  if 
professional  operators  are  not  used. 

4.4.3  Disadvantages 

•  Janus  can  play  a  300x300  km  box  if  terrain  of  sufficiently  low  resolution  terrain  data 
was  available.  The  limiting  factor  for  play  box  size  in  Janus  is  the  static  allocation  of 
the  terrain  arrays.  Janus  has  a  fixed  1000x1000  element  array  of  terrain  cells.  If  the 
terrain  resolution  is  200  meters,  the  maximum  play  box  is  200x200  kms.  Common 
terrain  resolutions  are  50,  100,  and  200  meters.  Increasing  the  array  allocation  to 
1500x1500  elements  to  accommodate  a  300x300  km  play  box  more  than  doubles  the 
memory  used  to  store  terrain  cell  data.  This  increase  alone  should  have  little  affect  on 
performance.  Janus  uses  about  a  third  of  the  Hewlett-Packard  715-50’s  64  Mbytes  of 
RAM.  There  is  room  for  growth  before  swapping  occurs.  The  performance  affects 
would  be  most  noticeable  during  scenario  initialization,  checkpoint  saves,  and 
graphical  updates  when  zooming.  An  alternative  is  to  modify  the  terrain  filter  utility 
to  create  lower  resolution  terrain  from  higher  resolution  master  terrain  files. 

•  Janus  6.88D  does  not  allow  units  to  be  inserted  into  play  or  removed  from  play  during 
execution.  It  also  does  not  provide  for  the  resurrection  of  dead  units. 

•  The  capability  to  give  an  aggregated  unit  a  movement  route  is  unsatisfactory.  When  a 
route  is  given  to  an  aggregated  unit,  the  route  is  copied  ‘In-line’  to  the  other  elements 
in  the  unit.  All  the  elements  in  the  unit  converge  on  the  first  movement  node  of  the 
route,  then  follow  the  route  to  the  end  in  an  irregular  column.  Unit  formation  and 
spacing  is  not  maintained  unless  the  unit  is  traveling  in  a  column  on  a  road.  To  make 
units  move  in  other  formations,  the  operator  must  either  give  a  movement  route  to 
each  element  of  the  unit  or  copy  the  route  to  other  elements  and  then  adjust  each 
route.  This  is  a  time  consuming  operation  that  limits  the  number  of  icons  that  a  user 
can  control. 

•  Janus  does  not  distinguish  between  rotary  and  fixed  wing  fliers.  Janus  only  has  a 
rotary  wing  model,  but  replicates  fixed  wing  aircraft  as  fast  helicopters. 

•  Janus  cannot  add  units  to  a  scenario  or  delete  units  from  a  scenario  during  execution. 
Without  the  ability  to  add  and  delete  units  and  without  the  ability  to  ‘hide’  units,  that 
is  stop  sending  entity  state  PDUs  for  a  unit,  Janus  cannot  be  used  as  the  exercise 
driver. 
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•  Janus  6000  was  specifically  tailored  to  meet  the  needs  of  CSTTAR.  The  ability  to 
hide  units,  the  ability  of  units  to  move  in  formation,  and  the  ‘Death  Angle’,  a  random 
attrition  feature,  have  not  been  included  in  Janus  6.88D.  It  will  take  TRAC-WSMR  8 
to  9  months  to  put  this  functionality  into  Janus  6.88D.  There  is  a  one  time  cost  of 
$250,000  and  an  annual  maintenance  fee  of  $1 10,000. 

•  Janus  7.0  is  the  current  Army  tactical  trainer  model.  Janus  7.0  has  multiple  kill 
categories,  hulks,  building  rubbling,  insertion  of  units  into  the  scenario,  repair, 
medical  aid,  and  obstacle  detection.  Janus  6.88D  lacks  all  these  capabilities.  It  is 
unlikely  that  the  training  community  will  be  willing  to  move  to  a  version  of  Janus  that 
lacks  features  deemed  necessary. 

4.4.4  Issues 

•  Janus  6.88D  would  require  some  upgrades  to  the  current  hardware  suite  used  by  the 
training  sites.  The  fielded  training  version  of  Janus  has  a  hardware  suite  consisting  of 
HP  series  9000,  715-50  workstations.  The  CSTTAR  experiment  used  a  HP  C-180 
workstation.  The  C-180  is  about  3.5  times  faster  than  the  715-50  workstation.  Even 
with  the  faster  workstation,  the  data  base  had  to  be  manipulated  to  run  the  exercise  in 
real  time.  A  workstation  faster  than  the  C-180  is  probably  required  for  the  host 
workstation.  The  current  715-50  workstations  can  be  used  for  display  workstations. 

•  Janus  6000  had  the  capability  to  maintain  an  aggregated  unit’s  formation  while  it 
maneuvered.  Terrain  effects  on  movement  were  ignored.  Only  the  column  formation 
is  supported  in  Janus  6.88D.  The  only  way  to  get  units  to  move  in  formations  other 
than  columns  is  give  individual  movement  routes  to  each  entity.  The  unit  would  have 
to  be  monitored  closely  during  maneuvers  so  adjustments  can  be  made  to  maintain  the 
formation.  This  implementation  does  not  have  much  utility  for  either  the  wrap¬ 
around  scenario  or,  in  the  case  of  Ft  Hood,  the  inner  training  scenario.  The  Janus 
6000  capability  can  be  put  back  into  Janus  6.88,  but  ignoring  the  effects  of  terrain  on 
movement  is  unacceptable  in  the  training  exercise  at  Ft  Hood.  The  ultimate  solution 
is  to  modify  Janus  so  that  1)  units  move  in  formation;  2)  terrain  affects  the  movement 
of  individual  entities  and  the  unit  as  a  whole;  3)  units  make  rounded  comers  instead 
of  pivoting  around  the  lead  unit  or  center  of  mass;  and  4)  units  circumvent  obstacles 
and  impassable  terrain  features  when  possible. 

•  Janus  can  only  play  a  200x200  km  play  box  because  lower  resolution  terrain  is 
unavailable.  To  achieve  the  full  300x300  km  play  box,  multiple  Janus  scenarios 
would  have  to  be  mn  simultaneously  for  the  wrap-around  portion.  Currently  Janus 
6.88D  cannot  be  used  as  the  simulation  driver  using  multiple  scenarios  is  it  does  not 
have  the  ability  to  add  or  delete  imits  during  play  or  the  ability  to  ‘hide’  units.  If  the 
ability  to  ‘hide’  units  were  put  into  Janus  6.88D,  the  boundary  between  wrap-around 
scenarios  would  be  treated  in  the  same  way  as  the  boundary  between  the  wrap-around 
scenario  and  the  exercise  scenario.  There  is  an  area  of  overlap  between  scenarios 
where  units  are  hidden.  Units  passing  through  two  or  more  scenarios  are  added  to 
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each  scenario  they  will  pass  through  during  scenario  creation.  When  a  unit  of  one 
scenario  enters  a  ‘hide’  zone  between  adjoining  wrap-around  scenarios,  a  unit  in  the 
adjacent  scenario  will  leave  its  ‘hide’  zone.  While  the  scheme  is  workable,  it  adds  a 
great  deal  of  complexity  to  the  m^lnagement  and  planning  of  the  wrap-around  scenario 
and  requires  a  great  deal  of  coordination  between  operators. 

•  Increasing  the  Janus  play  box  from  200x200  km  to  300x300  km  by  either  increasing 
the  terrain  cell  array  or  by  reducing  terrain  cell  resolution  will  have  an  adverse  affect 
on  performance.  This  is  because  the  additional  50,000  square  kilometers  would  have 
terrain  features.  LOS  and  movement  algorithms  both  search  terrain  features.  The 
addition  of  a  terrain  feature  geometrically  increases  the  time  required  to  perform  LOS 
calculations.  The  affect  on  performance  would  be  less  on  the  relatively  barren  Ft 
Irwin  and  Ft  Hood  terrains  than  at  other  CTC  sites. 

•  Janus  will  be  made  HLA  compatible  in  the  future.  At  this  time  it  is  not  known  which 
of  the  Janus  versions  will  become  the  HLA  version  or  what  functionality  will  be 
included  in  it. 


4.5  BBS 

4.5.1  Model  Description 

The  Brigade/Battalion  Battle  Simulation  (BBS)  is  used  for  command  post  exercise  (CPX) 
training  support.  Its  intended  training  audience  is  the  BDE/BN  commanders  and  staff. 
BBS  is  a  two-sided,  free  play  simulation  set  in  a  real-time  environment.  The  simulation 
supports  maneuver,  fire  support,  air  defense,  engineering.  Nuclear,  Biological,  Chemical 
(NBC)  warfare,  tactical  air,  air  transport.  Army  aviation,  logistics,  maintenance,  medical, 
personnel  administration,  higher  headquarters  functions,  and  threat  operations.  Its 
strengths  are  combat  support  and  combat  service  support,  not  tactics  and  maneuver.  BBS 
is  not  an  entity  level  simulation.  It  is  neither  DIS  nor  HLA  compliant. 

4.5.2  Advantages 

•  BBS  is  an  aggregate  level  simulation.  Operators  should  be  able  to  control  more 
entities. 

•  BBS  supports  aggregation  and  de-aggregation  of  units  during  play. 

4.5.3  Disadvantages 

•  BBS  is  not  an  entity  level  simulation.  Entities  within  an  unit  do  not  have  locations 
and  direction  of  movement. 

•  There  are  no  plans  to  make  BBS  HLA  compliant. 
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•  BBS  is  not  DIS  or  HLA  compliant. 

•  The  typical  BBS  play  box  is  50x50  km. 

•  BBS  does  not  use  the  same  hardware  as  the  current  tactical  combat  trainer. 

4.5.4  Issues 

•  BBS  is  not  an  entity  level  simulation,  does  not  support  DIS  or  HLA,  and  does  not 
support  a  300x300  km  play  box.  It  cannot  be  recommended  for  CSTAR. 


4.6  STOW 

4.6.1  Model  Description 

STOW  is  a  suite  of  software  and  hardware  used  to  link  virtual  and  constructive 
simulations.  On  one  side  is  the  constructive  simulation  BBS  (or  EAGLE).  BBS  is  an 
aggregate  level  model,  not  an  entity  based  model.  On  the  other  side  is  a  DIS  network 
consisting  of  ModSAF  and  manned  virtual  simulators.  ModSAF  is  a  semi-automated 
force  model  that  models  vehicles  in  detail  to  populate  the  virtual  world  of  the  manned 
simulators.  Between  BBS  and  ModSAF  is  an  Operational  State  Interpreter  (OPSIN). 
The  OPSIN  passes  information  on  aggregated  BBS  units  to  ModSAF  when  such  units 
enter  into  the  Sphere  Of  Influence  (SOI)  of  a  manned  simulator.  ModSAF  de-aggregates 
the  unit  into  separate  entities  and  positions  them  based  on  their  formation.  BBS  retains 
control  of  the  unit.  ModSAF  sends  out  entity  state  DIS  PDUs  for  the  separate  entities  of 
the  BBS  unit.  The  OPSIN  also  communicates  back  to  BBS  the  results  of  engagements 
between  elements  of  BBS  aggregates  and  the  manned  simulators.  BBS  units  are  de- 
aggregated  only  when  they  enter  a  sphere  of  interest  of  one  of  the  manned  simulators. 
The  unit  is  dropped  from  ModSAF  when  it  leaves  the  SOI  of  the  maimed  simulator.  The 
manned  simulators  are  not  needed  for  CSTAR. 

4.6.2  Advantages 

None. 

4.6.3  Disadvantages 

•  STOW  uses  a  aggregate  level  simulation.  Aggregated  units  are  only  decomposed  into 
individual  entities  when  the  units  come  in  range  of  a  manned  simulator.  At  all  other 
times,  individual  entities  do  not  a  specific  location  or  direction  of  movement. 

•  The  main  drawback  is  that  STOW  requires  both  a  BBS  and  ModSAF  suite  of 
hardware.  ModSAF  is  required  to  provide  entity  level  information.  BBS  does  not 
provide  anything  to  CSTAR. 
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•  Both  BBS  and  ModSAF  typically  use  a  50x50  km  play  box. 

4.6.4  Issues 

•  A  scheme  of  using  an  aggregate  level  simulation  to  model  a  large  force  which  passes 
off  selected  units  to  ModSAF  to  de-aggregate  and  model  in  greater  detail  would 
provide  sufficient  detail  to  simulate  various  sensor  models.  Using  enough  ModSAF 
workstations  to  decompose  all  of  the  BBS  aggregated  units  into  entities  is  not 
feasible.  The  alternative  is  to  develop  a  mechanism  to  communicate  to  the  OPSIN  the 
SOI  of  the  various  sensor  models  so  that  only  those  units  that  are  of  possible  interest 
to  the  sensor  models  are  decomposed  into  entities.  The  HRSS  was  the  interface 
between  the  sensor  models  and  the  virtual  simulation  for  the  CSTTAR  experiment.  It 
may  be  possible  for  the  HRSS  to  relay  the  sensor  footprint  to  the  OPSIN.  It  would 
require  building  interfaces  between  the  HRSS  and  the  OPSIN  and  modifying  the 
HRSS  and  possibly  the  OPSIN.  This  scheme  increases  the  complexity  of  the  system. 
A  more  serious  defect  is  that  the  BBS  units  do  not  become  part  of  the  virtual  scenario 
expect  through  ModSAF,  and  then  only  for  short  periods  of  time.  There  are  no  PDUs 
for  the  BBS  units  to  log  so  most  of  the  wrap-around  scenario  is  left  out  of  the  After 
Action  Review  (AAR). 


4.7  ModSAF 

4.7.1  Model  Description 

ModSAF  is  a  semi-automated  forces  model.  ModSAF  simulates  a  wide  range  of  air  and 
ground  combat  vehicles  and  personnel  including  tanks,  infantry  fighting  vehicles, 
individual  combatants,  mortars  and  artillery,  air  defense  systems.  Armored  Personnel 
Carriers  (APC),  command  posts  and  maintenance  and  supply  vehicles,  aviation  elements, 
close  air  support,  minefields  and  breaching  equipment.  The  primary  role  of  ModSAF  is 
to  provide  entities  for  manned  simulators  to  interact  with.  ModSAF  entities  are  modeled 
in  a  great  deal  of  detail  to  achieve  the  necessary  realism  required.  ModSAF  can  also  be 
used  as  a  tool  for  training  tactics  and  command  and  control  procedures  for  unit 
commanders  and  their  staffs.  ModSAF  or  one  of  its  derivatives  is  tentatively  scheduled 
to  become  the  army’s  company  level  tactical  trainer  in  the  future.  ModSAF  may  also  be 
used  for  analysis  and  mission  planning.  ModSAF  is  fully  DIS  compliant.  A  scenario  can 
be  distributed  over  a  virtually  unlimited  number  of  workstations  to  reach  the  desired 
number  of  entities. 

4.7.2  Advantages 

•  ModSAF  is  already  fully  DIS  compliant.  ModSAF  has  a  HLA  gateway  which  should 
be  sufficient  for  CSTAR. 
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•  ModSAF  runs  on  a  number  of  platforms,  including  Sun,  SGI,  HP,  DEC  alpha,  and 
Pentiums  running  Linux.  ModSAF  comes  with  a  PDU  logger. 

•  ModSAF  supports  the  organization  of  entities  into  multi-level  hierarchies. 

•  Units  can  be  added  to  a  scenario  on  demand. 

•  ModSAF  has  the  capability  to  capture  the  live  NTC  play  to  create  a  virtual  scenario. 

4.7.3  Disadvantages 

•  To  model  ModSAF  entities  in  the  detail  needed  for  manned  simulators  consumes  a  lot 
of  CPU  time.  This  means  that  only  60  to  120  entities  can  be  modeled  per 
workstation.  To  achieve  an  8000  entity  count,  a  minimum  of  65  workstations  and 
operators  would  be  required.  This  makes  ModSAF  prohibitively  costly  as  the  wrap¬ 
around  exercise  driver  for  CSTAR.  If  ModSAF  could  improve  its  performance  to  the 
point  where  it  can  handle  200  plus  entities  on  a  workstation,  it  would  become  a 
practical  alternative  to  either  Janus  or  JCATS. 

•  ModSAF  has  a  number  of  memory  leaks.  Memory  leaks  occur  when  memory  is  not 
released.  Eventually  the  workstation  runs  out  of  memory  and  crashes.  The  memory 
leak  problem  makes  the  goal  of  running  for  24  hours  doubtful.  In  at  least  one  version 
of  ModSAF  enough  of  the  leaks  have  been  plugged  that  ModSAF  can  run  over  24 
hours.  As  these  fixes  are  integrated  into  the  base  line  ModSAF  should  be  able  to  run 
longer. 

•  The  typical  size  exercise  box  for  ModSAF  is  50x50  km. 

4.7.4  Issues 

•  ModSAF  has  already  been  ported  to  Pentiums  running  Linux.  Pentiums  are  a 
relatively  cheap  platform  and  become  more  attractive  as  they  become  faster.  But  any 
potential  gains  in  the  number  of  entities  that  ModSAF  can  play  will  likely  be  offset 
by  enhancements  to  improve  and  broaden  the  model. 

•  ModSAF  is  more  complex  and  difficult  to  learn  than  Janus.  It  would  require 
additional  training  time  for  operators  or  the  use  of  a  professional  staff 

•  ModSAF  is  fully  DIS  compliant.  It  sends  out  entity  state  PDUs  every  five  seconds 
for  stationary  units,  and  more  often  for  moving  units.  Janus  and  JCATS  update  units 
less  often  and  therefore  send  fewer  entity  state  PDUs.  ModSAF  also  sends  out  more 
types  of  PDUs.  The  total  number  of  PDUs  put  out  by  ModSAF  may  not  overload  the 
network,  but  may  overwhelm  the  HRSS. 
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4.8  CBS 

4.8.1  Model  Description 

The  Corps  Battle  Simulation  (CBS)  is  a  Man-in-the-Loop  simulation  which  supports 
training  of  a  corps  commander  and  his  battle  staff,  major  subordinate  commands,  and 
major  subordinate  elements  of  headquarters  of  the  corps  in  conduct  of  deep  operations, 
air-land  battle  operations.  It  exercises  command  and  staff  skills  in  the  control  of  joint 
operations,  tactical  forces,  combined  arms  forces,  maneuver  forces,  and  the  combat 
support  and  combat  service  support  systems  in  an  operational/tactical  environment.  The 
simulation  supports  maneuver,  fire  support,  air  defense,  engineering,  NBC  warfare, 
tactical  air,  and  logistics.  CBS  is  not  an  entity  level  simulation.  It  is  neither  DIS  nor 
HLA  compliant. 

4.8.2  Advantages 

•  CBS  is  a  aggregate  level  simulation.  Operators  should  be  able  to  control  more 
entities. 

•  The  CBS  exercise  box  exceeds  the  300x300  km  requirement. 

•  CBS  supports  aggregation  and  de-aggregation  of  units  during  play. 

4.8.3  Disadvantages 

•  CBS  is  not  an  entity  level  simulation.  Entities  within  an  unit  do  not  have  locations 
and  direction  of  movement. 

•  There  are  no  plans  to  make  CBS  HLA  compliant. 

•  CBS  is  not  DIS  or  HLA  compliant. 

•  CBS  does  not  use  the  same  hardware  as  the  current  tactical  combat  trainer. 

4.8.4  Issues 

•  CBS  cannot  be  recommended  for  CSTAR  because  it  is  not  an  entity  level  simulation, 
and  does  not  support  DIS  or  HLA. 


5.0  RECOMMENDED  MODELS 

The  entity  based  models  received  the  greatest  consideration  in  this  study.  The 
functionality  of  the  models  were  compared  against  the  CSTAR  requirements  and  the 
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functionality  of  the  other  candidate  models.  Other  factors  include  the  level  of  operator 
interaction  required  to  manage  a  large  number  of  entities,  compatibility  of  the  model’s 
hardware  with  the  existing  hardware,  and  the  training  benefits  of  the  competing  models 
examined. 

JCM  was  not  recommended  because  it  will  not  be  supported  after  mid  1998,  it  runs  on  a 
different  platform  than  the  current  training  model,  and  it  will  not  be  made  HLA 
compliant.  JTS  was  rejected  because  it  will  not  be  supported  after  mid  1998,  it  requires 
purchasing  COTS  software,  it  does  not  support  aggregation  of  entities  into  multi-level 
hierarchies,  and  it  will  not  be  made  HLA  compliant.  BBS  was  rejected  because  it  is  not 
an  entity  level  model  and  is  not  DIS  or  HLA  compatible.  ModSAF  was  not 
recommended  because  the  hardware  and  operators  required  to  manage  a  large  number  of 
entities  is  prohibitive  and  the  model  is  not  stable  at  this  point.  CBS  was  rejected  because 
it  is  not  an  entity  level  model  and  is  not  DIS  or  HLA  compatible.  STOW  was  not 
recommended  because  it  has  the  same  flaws  as  BBS  and  ModSAF,  to  model  all  the 
simulated  entities  is  redundant,  and  there  is  no  filtering  mechanism  to  model  only  the 
portion  of  the  entities  of  interest  to  the  sensor  models. 


5.1  Janus  6.88D 

This  study  recommends  the  use  of  the  analytical  Janus  6.88D  simulation  provided  that  the 
ability  to  hide  units  is  put  back  into  the  model.  Strong  consideration  should  also  be  given 
to  restoring  the  movement  of  aggregates  that  maintain  formation  and  the  ability  to  adjust 
the  PDU  output  rate.  The  determining  factor  is  the  schedule.  The  modifications  can  be 
made  to  Janus  in  eight  to  nine  months.  It  is  unknown  at  this  time  when  a  DIS  or  HLA 
compliant  version  of  JCATS  will  be  available. 


5.2  JCATS 

JCATS  appears  to  be  the  best  model.  JCATS  will  be  able  to  play  more  entities  than 
Janus  and  will  not  have  to  resort  to  manipulating  the  data  base  to  maintain  real  time. 
JCATS  can  accommodate  a  300x300  km  exercise  box  where  Janus  will  have  to  run 
multiple  scenarios  to  achieve  the  same  coverage.  JCATS  has  a  fixed  wing  aircraft  model. 
Janus  models  fixed  wing  aircraft  as  helicopters.  Units  can  he  added  and  removed  from 
JCATS,  but  not  Janus,  during  play.  JCATS  also  has  the  ability  to  deploy  units  during 
play.  JCATS  provides  more  useful  and  robust  control  over  aggregated  entities.  JCATS 
supports  more  formations  than  Janus.  The  modeling  of  movement  and  acquisition  for 
aggregated  units  loses  some  fidelity  compared  to  a  pure  entity  level  model  such  as  Janus. 
JCATS  can  be  fielded  at  training  sites  through  NSC  with  no  software  costs.  At  this  time 
it  is  not  known  whether  version  1 .0  will  be  DIS  compliant.  It  will  not  be  HLA  compliant. 
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This  would  seem  to  eliminate  it  as  the  constructive  simulation  driver.  A  number  of 
options  were  considered. 

One  option  considered  was  to  use  Janus,  JCM,  or  ITS  until  JCATS  becomes  DIS  or  HLA 
compliant.  Use  of  JCM  in  the  interim  is  possible  but  costly.  JCM  does  not  run  on  the 
same  hardware  as  either  the  current  training  model  or  JCATS.  It  would  require  buying 
hardware  that  will  used  for  only  a  short  period  of  time.  The  use  of  JTS  as  an  interim 
simulation  is  not  feasible  either.  JTS  can  use  the  same  hardware  as  the  current  training 
model  and  JCATS  but  requires  the  purchase  of  expensive  COTS  software  which  would 
not  be  used  once  JTS  is  replaced.  Another  factor  weighing  against  JTS  is  it  does  not 
support  the  organization  of  entities  into  multi-level  hierarchies.  This  reduces  the  number 
of  entities  that  can  be  controlled  by  each  operator. 

If  DIS  compliant,  serious  consideration  should  be  given  to  incorporate  JCATS  as  the 
constructive  simulation  after  it  is  released  in  April  or  May  1998.  The  capabilities 
advertised  for  JCATS  meet  more  of  the  CSTAR  requirements  than  Janus.  Additionally 
the  second  JCATS  release  in  August  or  September  1998  may  be  HLA  compliant  and  thus 
should  enable  a  smooth  transition  to  the  Warfighter  Simulation  2000  (WARSIM)  and 
WARSIM  Intelligence  Module  (WIN)  when  they  become  available. 


6.0  IMPLEMENTATION  /  INTEGRATION  APPROACH 
(REQUIREMENT  REMOVED  FROM  UDO,  IPR,  13  NOV  97) 

6.1  Discussion  (REQUiREMENT  REMOVED  FROM  UDO,  iPR,  13  NOVN  97) 

This  approach  includes  developing,  testing  and  installing  the  CSTAR  simulation  at  FT. 
Irwin,  NTC  and  a  “home  station  training”  suite  at  FT.  Hood,  TX.  We  intend  to  develop 
procedures  and  test  the  constructive  simulation  with  the  interface  of  the  Intelligence 
Models  JSTARS,  Guardrail  and  UAV  it  stimulates  in  Orlando  with  follow-on  testing  at 
Ft  Hood  and  at  FT.  Irwin,  NTC. 


6.2  FT.  Hood,  TX.  (REQUiREMENT  REMOVED  FROM  UDO,  iPR,  13  NOV  97) 

6.3  FT.  irwin,  CA.  NTC.  (REQUiREMENT  REMOVED  FROM  UDO,  iPR,  13 
NOV  97) 

7.0  ACRONYMS  AND  ABBREVIATIONS 
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AAR 

After  Action  Review 

APC 

Armored  Personnel  Carriers 

ASAS-RWS 

All  Source  Analyst  System-Remote  Workstation 

BBS 

Brigade/Battalion  Battle  Simulation 

BLUFOR 

blue  force 

CBS 

Corps  Battle  Simulation 

CCB 

Configuration  Control  Board 

CGS 

Command  Ground  Station 

CIS 

Central  Instrumentation  System 

COTS 

Commercial  Off  The  Shelf 

CPU 

Central  Processing  Unit 

CPX 

command  post  exercise 

CSTAR 

Combat  Synthetic  Training  Assessment  Range 

CSTTAR 

Combat  Synthetic  Test  and  Training  Range 

CTC 

Combat  Training  Centers 

DEC 

Digital  Equipment  Corporation 

DIS 

Distributed  Interactive  Simulation 

FAS 

Feasibility  Analysis  Study 

Gbyte 

giga  byte 

HLA 

High  Level  Architecture 

HP 

Hewlett-Packard 

HRSS 

High  Resolution  System  Stimulator 

lEW 

Intelligence  Electronic  Warfare 

IPR 

in  progress  reviews 

JCATS 

Joint  Conflict  and  Tactical  Simulation 

JCM 

Joint  Conflict  Model 

JTS 

Joint  Tactical  Simulation 

JSTARS 

Joint  Surveillance  Target  Attack  Radar  System 

LOS 

Line  Of  Sight 

Mbytes 

mega  byte 

MI 

Military  Intelligence 

ModSAF 

Modular  Semi  Automated  Forces 

NBC 

Nuclear,  Biological,  Chemical 

NTC 

National  Training  Center 

OPFOR 

opposing  force 

OPSIN 

Operational  State  Interpreter 

PDU 

Protocol  Data  Unit 

RAM 

Random  Access  Memory 

SGI 

Silicon  Graphics,  Inc. 

SIGINT 

Signals  Intelligence 

SOI 

Sphere  Of  Influence 

SOW 

Statement  Of  Work 

STOW 

Synthetic  Theater  Of  War 
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STTAR 

Combat  Synthetic  Test  and  Training  Range 

TCS 

Tactical  Control  System 

UAV 

Unmanned  Air  Vehicle 

UDO 

Unilateral  Delivery  Order 

VAXWMS 

Virtual  Address  Extension/Virtual  Memory  System 

VMS 

Virtual  Memory  System 

WARSIM 

Warfighter  Simulation  2000 

WGS 

World  Geodetic  System 

WIN 

WARSIM  Intelligence  Module 

WRAP 

Warfighter  Rapid  Acquisition  Program 

WSMR 

White  Sand  Missile  Range 
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Appendix  A  Constructive  Simulation  Model  Matrix 
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